Understand AOM Properties and Attribute Reflection
On this page
What is the Accessibility Object Model (AOM)?
The Accessibility Object Model is a set of APIs being designed by the Web Incubator Community Group with the goal of allowing JavaScript developers to modify and explore the accessibility tree for a web page.
The AOM is currently under development, and is subject to change. The purpose of this section is to show you what is available now, and what might be available in the future.
The AOM would give us another avenue for accessibility so that we could have a raw JavaScript access point without having to go through the HTML and ARIA that we currently use.
Look around the AOM GitHub repository and read more about the current status of the project. They have an explainer, spec, and more for you to read and explore.
HTML and ARIA Drives the Shape of the Accessibility Tree
We've talked about the accessibility tree a little bit and seen it in action in the Accessibility panel of Chrome’s DevTools.
The accessibility tree information includes roles, states, and properties for an entire page’s worth of elements, minus irrelevant things like scripts and meta tags.
When inspecting the date picker, the accessibility tree shows it lives in a region named ‘Site description and booking calendar’ and has a role of table with a label of ‘September 2022.’
This accessibility information is made available for Assistive Technologies thanks to the browser DOM and Accessibility APIs on the operating system working together.
The markup that we use is a primary driver for what accessibility information will be exposed. The implicit roles of our element tag names and the ARIA attributes (e.g. aria-label, aria-pressed) that we use in our HTML all contribute to this accessibility information.
The goal of AOM is to expose a raw JavaScript access point to that accessibility information that allows developers to bypass the HTML step. AOM has been an exciting prospect for developers of highly dynamic web applications with thousands of element nodes, where performance is a factor.
Understand AOM through the Document Object Model
A great way to start to understand AOM better is to look at an object model that you might be familiar with already.
Every time you open DevTools, the Document Object Model is right there.
Here’s a quick overview of the DOM:
Whether using a JavaScript library like React or with vanilla HTML, the tags we write with angled brackets, names, and attributes are rendered into a document seen in the DevTools elements pane. Through this process, our element tags have turned into objects in the browser that have meaning. DOM APIs then allow you to access and manipulate what you see through JavaScript. Example APIs include functions for getting/setting attributes and creating event handlers.
The AOM builds on this concept, but for objects and object properties specifically related to accessibility.
For example, in the DOM the aria-activedescendant attribute is used to identify the currently active item in elements like a radio group.
Instead of going through the DOM to manipulate which item has the ARIA attribute, we could set a property in the AOM and handle it in JavaScript directly. AOM would then do the work of updating the DOM for us automatically, where applicable.
Video Transcript
We have one more section to talk about, which is the accessibility object model. And this is kind of a futuristic concept that you might see out in the world. And so I wanted to include it so that you know what it is, and kind of get sort of a.
Level set on what's available to you and what could come in the future. So when we talk about accessibility object model, what is that? Well, it's really an incubation project for a variety of ideas. Some that are shipping and browsers and some that have been proposed or dreamt up, but either aren't going to come to fruition or are going to take a while.
I'm going to flip back over to Chrome over here. Within our project directories. So for exercise five, what is AOM? This read me in here has a bunch of information about the accessibility object model, including how to enable it and a link to where a lot of the work is happening. So for AOM, as we call it, it is a, an initiative under the web incubator community group.
For the accessibility object model. And this is really the, the place you can find the most up-to-date information about what's happening with it. Now, in a nutshell as they say this effort aims to create a JavaScript API, to allow developers to modify and eventually explore the accessibility tree for an HTML page.
We've talked about the accessibility tree a little bit. We've seen it a little bit in action over here in our accessibility panel. So our accessibility tree information includes things like roles you know, properties states. So all of that information from the accessibility tree. is something that the, the browser and the operating system are creating together to output accessibility information for assistive technologies.
And a lot of that hinges off of our markups. You know, we've seen how we can affect the accessibility tree with implicit roles in our element tag names, how we can bolt-on aria information. And so a lot of that stuff, you know, that's, that's ways that we can impact the accessibility tree today. And a lot of it comes from these attributes.
So things like aria label, aria-pressed, you know, all of those things that we saw come from the ARIA specification, those really hinge on attributes. That we weave into our HTML. So we have to kind of go through HTML to get to this accessible structure. The goal of AOM would be to make it so that we can just have like a raw JavaScript access point to that accessibility information without having to go through HTML is kind of an intermediary.
So really what we're talking about here are properties of these objects as opposed to attributes, and I'll show you examples of those differences in a little bit. But it can help to talk a bit about the document object. So the document object model we S we are looking at right now in our developer tools, we've gone from code in our text editor, you know, we're using react and JSX to compile our document, but those underlying tags, you know, kind of drilling all the way down into HTML tags that use those angle brackets and tag names like main and table.
And. Those tags that we write in raw HTML become objects. And those objects in the browser have meaning they have information. They have API APIs that we can call things on those objects. So the accessibility tree and the accessibility object model kind of build on that concept to have accessibility, specific objects.
And in AOM, they've really been aiming to give us the ability to, like I said, to sort of bypass HTML. So we're not having to do everything through attributes and there's some use cases like. If we were working with like, let's see, I'm going to pull up aria for this example. So, there's a, an aria active descendant.
This is a good candidate for where AOM could help us. So ARIA active descendant is a property that can identify a currently active element in the. So things like text boxes, applications you know, that's the menus radio groups. There's, there's various applications for this support. Hasn't always been the best.
So it's, I wouldn't say it's something that I use a lot. To set an aria active descendant. That's like, you know, you have one item out of a group that say is the focusable item or the active item that all historically we've had to go through this attribute, whereas AOM would allow us to use JavaScript to just set a property right there in JavaScript and not really worry about these attributes.
Enable AOM Support in Chrome or Firefox
Because the AOM is experimental there are a couple steps that you need to take to actually use it in Chrome or Firefox.
Safari includes AOM support without additional configuration.
In Chrome, go to chrome://flags and enable ‘Experimental Web Platform Features.’
In Firefox, you will need to navigate to about:config and search for accessibility.
There are two options that need to be flipped on, accessibility.AOM.enabled and accessibility.ARIAReflection.enabled.
After enabling the flags in your browser, you will be able to use the parts of AOM that have shipped.
Video Transcript
So AOM. To enable it to enable the functionality that we do have. In Chrome, we can go to Chrome colon slash slash flags, and we can go to experimental web platform features. So I already have this enabled, but if you didn't, you could search for it. Enable web platform, plat form. or wait experimental web platform features.
If you wanted to go and search for that that one will bring with it. Some AOM functionality there's also over in Firefox, get out of this cute, cute interstitial thing. So in Firefox, we would go to about colon config. And then in here I could type in accessibility dot AOM and that's where I can turn AOM on and off.
And so that should enable some of this functionality for what has shipped.
Explore AOM Properties vs. HTML Attributes through Attribute Reflection
A big concept that AOM introduces is the the idea of working with properties instead of attributes.
An attribute is a value that modifies an HTML element’s configuration and can be seen in the document.
For example, you can see the aria-label attribute set to “Page listing information” on this section element:
On the other hand, the AOM concept of working with properties would allow us to directly access the value of “Page listing information” through the ariaLabel property instead of having to get it through HTML and ARIA first.
AOM aims to represent the same information from accessibility attributes with properties that are easily queried through JavaScript objects. This might seem like a nuanced difference. But it would become more relevant in a web application where JavaScript object notation for accessibility could improve performance, such as setting an active descendant in a component with thousands of nodes.
To demonstrate AOM, with DevTools we can copy the selector string for the previous month button in the date picker component.
Then in the browser console, create a new variable called button and set it to the result of calling document.querySelector with the pasted-in button selector.
const button = document.querySelector('#main > div > section > div.wide-layout.two-parts-70-30 > div:nth-child(2) > div > header > button.btn-month.btn-prev')Now the button variable returns an object reference for the actual button in the DOM, with which we can interact in the JavaScript console.
With AOM enabled, we can type button.role in the console to look for an explicitly assigned role.
In this case button.role is null:
Note that button has an implicit role of “button” that the AOM didn’t recognize. Currently the AOM only recognizes explicitly added roles.
This is called attribute reflection.
If a property is set on the object with AOM, it will reflect as an attribute on the underlying DOM element.
Another attribute we can inspect as a property on the accessibility object is aria-label.
Writing button.ariaLabel in the JavaScript console will return “Previous month June” as that attribute has been explicitly bolted on to the element and is being reflected into the property.
AOM gives us the promise of a property-driven approach to get and set our site’s accessibility features directly through an object.
Even though this technology is still under development, it is worth becoming familiar with so that we can start using it as new features are officially released.
Video Transcript
so some of the ideas I mentioned, AOM is kind of an incubator project for different ideas. And the most up-to-date information. Can be found on this AOM project. So some things that it does, like I talked a lot about ar ia properties versus attributes.
So like an attribute is something that we see in the document. So like aria dash label, that's an attribute. The underlying object, you know, if it had an ARIA label property what AOM can do, and I can show this to you in the browser. So let's say, let's say for our camp spots are actually, let's pick something that hasn't already labeled.
So like this button down here and this June button, I'm going to go inspect it. I'm not going to in the dev tools, copy it's selector. because then I can come in here in the dev tools and do some crafty stuff. So I could say, create a variable like const. I'll just call it a button for the moment. And then I'm going to say document.querySelector.
And paste in this selector for this specific buttons. Now I have a handle on this. I can type button and it gives me a reference to this thing in the Dom. So I can inspect it using some AOM features. So button, if it had a role bolted on, I could. Test for that. So this has an implicit role, something that's I wish would return.
But AOM doesn't currently, it will only return button.Role as a property. If it actually has button, let's say. Or maybe I could say button.role equals button. So what that did is what's called attribute reflection. So I set it's role property. That is an AOM feature accessibility object model.
And it did what's called attribute reflection where it added the role role attribute onto the element. So that is a function of AOM is what's called attribute reflection. So if we set a property, it will reflect it as an attribute, so that as developers, we can see what's going on with this object under the hood.
If it didn't do attribute reflection like that, we would have no idea that it had this property set, I guess, where it becomes a little confusing from my perspective. Is that this button already had a role. It had an implicit role, but until we bolted on roll button, which we don't need to do, I'm just showing this to you.
So, you know, what attribute reflection is until it has a role, or if it has a role Bolted on like that button.Role and AOM is not really that useful. It's not giving us a computed role. So, I dunno if that's going to change. But that's, you know, if you're kind of playing with AOM and wanting to know kind of how this stuff works, it will only read if it has this explicit attribute bolted on Because we don't really need this.
This role is extra. Button role is exposed pretty much everywhere. There's no, it's not like the unordered list issue we saw in safari where we were going to go bolt list on a, we don't really need to do that with button, if it has an implicit role of button what we can do here. However, so this button has an aria label.
That's an attribute currently that we've used. We've. Bolted on aria-label attribute to supply accessibility information to this button. And so it's accessible object, something that's in the accessible accessibility tree. It does have an aria-label attribute. We could also with AOM enabled, say aria label as a property.
And it is showing us this aria label. The attribute is being reflected into the property. So because that is bolted on, we can check it. We can query it. In browsers that support this. So it's cool that it exists. I think it's kind of a futuristic technology. But as you saw, we had to enable it. I had to go into Firefox and enable it and Chrome to enable it.
Maybe some point in the future, it'll just be enabled and all the main browsers. But it's sort of. It's like a promising technology. That's kind of, not quite there yet. What would be more reliable if I wanted to query a label on something would be to say aria dash label.
So that returns the same thing. AOM could give us the property, but the attribute. You know, kind of going through the Dom and going through our HTML as I was talking about that's way wider supported. So other than kind of experimentation and playing, I would say, you know, in kind of a real world context, it's more likely that you would need to use something that's well-supported like get attribute or set attribute.
But the promise of AOM is that we'll have this JavaScript. Property driven approach that we can kind of get and set things on are our accessibility tree and accessibility objects. That's pretty cool though. I like that. I can. I mean, it's fun to play, right. And it's really fun to play with stuff that's underlying accessibility information.
So attribute reflection. That's what that means. It's, you know, making sure that if there's an underlying property for an object that it's reflected in the attributes so that you know that it's there.